1 



GLOBALIZATION MANAGEMENT SYSTEM AND METHOD THEREFOR 
BACKGROUND OF THE INVENTION 
FIELD OF THE INVENTION 
This invention directs itself to a system for managing the resources 
defined as code, content and graphics, of multiple interrelated and multilingual 
web sites. Further, this invention directs itself to a method for automatically 
updating the resources of web sites identified as subscribers responsive to 
changes in a resource on one or more source or provider sites. More in particular, 
this invention is directed to a system which provides the infrastructure for 
managing the deployment of multilingual resources across a network of 
globalized web sites. Still further, this invention provides a method for 
coordinating resources and managing globalization activity updates across 
multiple, multilingual web sites. Still more in particular, this invention provides 
the means to detect changes throughout a client's network of globalized web 
sites, automatically triggers localization of a global resource according to 
predetermined schedules, processes and customer-defined business rules, and 
then updates the subscriber sites with the updated resources, directly, translated, 
or in a localized form. 



PRIOR ART 

Content management systems are known in the art. Heretofore, such 
systems, such as provided by VIGNETTE, INTERWOVEN, DOCUMENTUM, 
and others provided the means to manage the creation of content and resources 
for web site content for a particular site. However, such systems could not 
integrate a globalized network of web sites having non-uniform interrelationships 
therebetween. 

The present invention overcomes the limitations of the prior art by 
providing a globalization management system that complements existing content 
management systems to handle global content changes or updates with a 
minimum of manual intervention. Yet, the globalization management system of 
the present invention allows for defining the relationships between a company's 
multiple multihngual web sites, as well as additions and deletions of web sites. 
Additionally, the resources which are monitored can be added to, deleted, as well 
as provide for editing of tasks associated with various types of content. 



SUMMARY OF THE INVENTTON 
A system for managing the resources of multiple interrelated and 
multilingual web sites is provided. The system provides for automatic detection 
of updates at particular web sites, identifies the resource as requiring translation, 
or other changes, such as localization, and transfers the resource, in its translated 
or localized form to identified subscriber web sites. The system provides the 
means for managing complex interrelationships between multiple web sites of u 
user, which may be multilingual, or may cater to an audience requiring a 
particular presentation format or resource. 



BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram illustrating applications of the globalization 
management system of the present invention; 

FIG. 2 is a more detailed block diagram of the present invention; 

FIG. 3 is a diagram illustrating an application of the present invention; 

FIG. 4 is a block diagram representing the data flow within the present 
invention; 

FIG, 5 is a flowchart illustrating the present invention's resource staging 
scheme of the present invention; 

FIG. 6 is a flowchart illustrating the resource globahzation process of the 
present invention; 

FIG. 7 is a flowchart illustrating the globahzation analysis and evaluation 
process of the present invention; 

FIG. 8 is a flowchart illustrating the interim nationalization process of the 
present invention; 

FIG. 9 is a block diagram illustrating the target application interface 
architecture of the present invention; 

FIG, 10 is a flowchart illustrating the target application interface 
customization process of the present invention; 

FIG. 11 is a flowchart illustrating the globalization management set-up 
process of the present invention; 

FIG. 12 is a flowchart illustrating the globahzation management process of 
the present invention; 



FIG. 13 is a flowchart illustrating the user management process of the 
present invention; 

FIG. 14 is a schematic diagram illustrating a provider and subscriber 
model for user with the present invention; 

FIG. 15 is a flowchart illustrating the site-to-site relationship management 
process of the present invention; 

FIG. 16 is a flowchart illustrating the project management process of the 
present invention; 

FIG. 17 is a flowchart illustrating the project action process of the present 
invention; and, 

FIG. 18 is a flowchart illustrating the global resource translation process 
of the present invention. 



6 



DESCRIPTION OF THE PREFERRED EMBODIMENT 
A system for managing the resources of multiple interrelated web sites is 
provided to provide automatic detection of resource updates at particular web 
sites, identified as resource providers, transferring the updates to other sites, 
identified as subscribers, wherein the transferred resource may be translated 
and/or localized, as required. As illustrated in FIG. 1, each entity, company X, Y, 
and Z, is provided with a globalization management system 200x, 200y, 200z, 
respectively. Each of the company's web server systems 10, 12, 14 
communicates through a respective Intranet 30x, 30y, 30z with the globalization 
management system 200x, 200y, 200z. The globalization management system 
200x, 200y, 200z has the ability to interface with the local resource 
management^database system used within the web servers 10, 12 14, whether it is 
a VIGNETTE system, INTERWOVEN system, DOCUMENNTUM, or others. 
When web page content requires translation for use in one of the company's 
foreign language web sites, the globalization management system 200x, 200y, 
200z communicates with an electronic translation portal (ETP) 210 through a 
global computer network (Internet) 20. Thus, the system provides the means by 
which multilingual and multi-site web-site globalization can be efficientiy and 
substantially automatically managed. 

A more detailed view of the globalization management system is further 
illustrated in FIG. 2. An individual responsible for administration of a 
company's web sites communicates with the global contact management system 
utihzing a terminal 202 utilizing web browser software. The terminal 202 
communicates with a server 204 which receives data from the agent 208. Agent 



208 communicates through the Internet with the electronic translation portal 210 
as well as a remote target application interface 222, which is considered a 
backend data source for the system. Data being transmitted to server 204 from 
agent 208 is in the form of presentation 206, which is much like a web page. An 
active server pages (ASP) or Java server pages (JSP) template is utilized to 
collect information from the database and create the page 206 which is presented 
to the server 204 for transmission to the terminal 202, or alternately, to the 
electronic translation portal 210, through the Internet, in order to have that 
information translated for the operator of terminal 202. 

In use, as shown in the diagram of FIG. 3, a Company X has a computer 
network 10 which provides a web site 102 in the United States, a web site 104 in 
Japan, and at least one other web site 106 in another country. The globalization 
management system 200x maintains the resource relationships between the 
multiple sites by automatically updating, translating and localizing the data added 
to those sites identified as resource providers for incorporation in the subscriber 
sites. In the following example. Company X is a widget manufacturer with its 
primary site 102 created in English. Utilizing the translation portal 210 through 
the Internet link 20 one or more resources of the U.S. site 102 is translated into 
Japanese for use on the Japanese site 104 and French, for the site 106. Company 
X has manufacturing plants in the U.S., Japan and France, and therefore each of 
the respective web sites 102, 104 and 106 is identified as a provider for the other 
sites, which also therefore act as subscribers. For instance, if the Company's 
Japanese site posts an article dealing with possible changes in Japan's laws 
concerning how widgets are manufactured or sold in that country, that 
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information may be important to widget production and imports/exports in the 
United States and France. Therefore, with the Japanese site acting as provider, 
the globalization management system 200x will identify the newly posted article 
on the Japanese site, transmit that resource to the translation portal 210, and upon 
returned receipt of the translated resource, system 200x will then update the U.S. 
and French sites appropriately. In other cases, wherein content is strictly local, 
such as pricing or sales associated with locally observed holidays, no 
provider/subscriber relationship will exist for that content and an update in 
pricing on the French site will not affect any content on either the U.S. or 
Japanese sites. Thus, the globalization management system allows the 
subscription and provider relationships between the sites to be set up at different 
granularities such that items as small as individual paragraphs in a file and as 
large as entire web sites can have resources copied, translated and localized. 
Localization is the adaptation of shared web site resources from the resource 
provider to the subscriber to conform to the local culture and business customs of 
the subscriber locale. In addition to such content as product pricing, content 
relating to holiday promotions or containing particular colloquialisms will need 
adaptation for local sites, rather than direct translation. Although each of the web 
sites 102, 104, 106 includes local content editors and reviewers 4, 4', 4", use of 
the globalization management system 200x takes care of the problem of updating 
one site with respect to changes made at one of the others. 

Turning now to FIG. 4, there is shown the block diagram representing the 
data flow within the globalization management system. The globaHzation 
manager engine 100 communicates with the data sources of the U.S. and, for 



example, the Japanese web sites through a local target application interface (TAI) 
222' and a remote target application interface 222", respectively. Each of the 
respective interfaces 222', 222" has an open architecture for communicating with 
the data sources 1021 and 1022 used by the web site 102 and data sources 1041, 
and 1042, used by the web site 104, respectively. Thus, wherein the Japanese 
web site is in Enghsh, and therefore no translation is needed, the globalization 
manager engine 100 is able to identify changes in a resource, and appropriately 
transfer such from one data source of one web site to a data source of another. 

In FIG. 5, the globaUzation management system's resource staging scheme 
is shown. Web site resources are created by individuals. The creation of a 
resource goes through a number of stages, beginning with the development 
environment 300 wherein web site form and resources evolve. From the 
development envu-onment, there is next a staging environment wherein the 
resource is prepared and arranged. From the staging envkonment 302, the 
resource may be then published, from which it then goes to the production 
environment 306. The globalization management system 200 can replicate any of 
those environments, pullmg resources from the development environment, 
staging environment, publishing environment or production environment. Thus, 
the replication can take place in any of blocks 308, 310, 312 or 314, depending 
on the user's desires. The source and target environments are a function of such 
characteristics as the language of the resource and the culture into which it is 
targeted. Consider, a web site which has been developed in French for the 
culture in France which must then be replicated, to a certain degree, for use in 
Quebec, Canada. Although the language need not significantly change, there are 
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significant cultural differences which may affect the content. 

The flow chart in FIG. 6 will aid in understanding the process of resource 
globalization. Beginning from the start block 350, the process begins with a 
globalization analysis and evaluation in block 352. That process is further 
defined in FIG. 7, and will be discussed in following paragraphs. From block 
352, the flow passes to decision block 354 wherein it is determined whether the 
user's content management system needs to be internationalized (able to handle 
multiple languages). If it requires internationalization, the flow passes to block 
356 (further defined in FIG. 8). Subsequent to internationalization, the flow 
passes from block 356 to decision block 358. If internationalization was not 
required, flow passes from decision block 354 to decision block 358. In block 
358 it is determined whether target application interface customization is 
reqmred. Target apphcation interface customization deals with the selection of 
data sources from which the resource is derived, and if customization is required, 
the flow moves to block 360, which process is further defined in FIG. 10. 
Subsequent to customization, the flow passes to the global content manager setup 
procedure identified in block 362. If target application interface customization 
was not required, the flow passes from block 358 to block 362. The globalization 
manager setup of block 362 deals with configuration and initiaUzation of a 
number of subprocesses that are further illustrated in FIG. 11. 

From block 362, the flow then passes to block 364 which describes the 
management steps involved with management of global resources. From block 
364, the flow passes to block 366 wherein the system hibernates, goes to sleep for 
a predetermined period. By waiting a predetermined time period, the system is 
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allowing time for a resource to be changed on the source site(s). The time period 
could be in terms of minutes, hours, days, weeks, etc., whatever would be a 
reasonable cycle time for the type of web site, and/or business associated with the 
web site, that is the content source. After that predetermined time period, the 
flow then passes to block 368 wherein auto change detection is launched, and 
flow then passes to decision block 370. In block 370, it is determined whether 
there has been a change in content on the source site. If there has been a change, 
flow passes back to block 364 for managing that change. If no change has been 
detected, flow passes to decision block 372 where it is determined whether the 
user has requested the process to be shut down. If the process has not been 
requested to shut down, flow passes back to block 366 to await the next cycle. If 
the user has requested the shutdown of the process, flow passes to end block 380. 

The steps involved in the globalization analysis and evaluation, block 352 
of FIG. 6, are outlined in the flow chart of FIG. 7. From the resource 
globalization process, indicated at block 400, the flow passes to block 402 
wherein the customer's business approach, web architecture, processes and 
marketing readiness are analyzed and evaluated. From block 402, the flow 
passes to block 404, wherein it is determined the size of the web site and the 
number of target sites which the customer is to have, and in what countries they 
will reside. In block 404, it is determined what type of company management 
systems are to be used and whether those systems are going to use then" own 
native file format or whether they are going to integrate with other file formats or 
any other content management systems. From block 404, the flow passes to 
block 406. In block 406, it is determined how many target applications will be 
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needed to be created or supported, the type of target application interfaces 
needed, the integration method and the type of databases to be utilized as well. 
From block 406, the flow passes to block 408 wherein the interrelationships 
between sites is defined. For example, the U.S. site will subscribe resources into 
the Japanese site and some resource of the Japanese site may be subscribed to the 
U.S. site. 

From block 408, the flow passes to block 410 wherein it is determined 
which resource needs to be translated, which resource needs to be copied directly, 
and which content needs to be localized, or handled in some special manner or in 
accordance with particular business rules. From block 410, the flow passes to 
block 412 where it is decided how the system is to be deployed. For example, the 
customer can use any file management system or word processing system to 
deploy it, or they may use the content management system to deploy it. From 
block 412, the flow passes to block 414. In block 414, the local content editor, 
reviewer and translator are chosen. Those functions may be handled by 
mdividuals such as company employees, outside companies or contractors, or 
software packages which handle the function. From block 414, the flow passes to 
block 416, wherein the customer's software is accessed and evaluated as to its 
internationalization readiness, such as handling multiMngual input and/or output, 
different currencies, multiple time zones, etc. From block 416, the flow passes to 
block 418, wherein the flow is returned to block 352 of FIG. 6. 

In FIG. 8, the process for internationalization is shown. Beginning from 
start block 420, the flow passes to block 422 in which tiie customer's source code 
is analyzed and evaluated. That evaluation includes an analysis of tiie language 
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Utilized, the ability to handle different currencies and data information peculiar to 
any particular locale. In addition to the operating software, the user's databases 
are also checked to make sure they are ready and able to store data coming from 
worldwide sources. From block 422, the flow passes to decision block 424, 
wherein it is determined whether the database code needs to be changed. It is 
important that the database be a Unicode database, one which can accept data in 
all languages. If any database is not a Unicode database, the flow passes to block 
426, wherein the database is modified accordingly. From block 426 the flow 
passes to decision block 428, as does the flow from decision block 424 if no 
modification is required to the database. In block 428, it is determined whether 
the application server code, which may be JAVA, C++ or C, or any other 
program language, is able to process data from any of the different languages 
being supported by the multiple web site architecture. If the application server 
code requires modification, the flow passes to block 430 for such modification. 
If no modification is required, flow passes from decision block 428 to decision 
block 432. Likewise, subsequent to modification in block 430, the flow then 
passes to decision block 432. 

In decision block 432, it is determined whether the client application, i.e. 
WINDOWS chent, UNIX client, etc. can display the local information properly. 
If it cannot, and requires modification, the flow then passes to block 434 wherein 
it is modified accordingly. If no modification is required, the flow passes ft-om 
decision block 432 to decision block 436. If modification was required, the flow 
passes from block 434 to decision block 436. In decision block 436, the chent' s 
front end web-based client code is checked to ensure that it is internationally 
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ready. If modification is required, flow passes to block 438, wherein the 
modifications are made so that the front end web-based client software can 
process and display data from all of the required languages. If no modification is 
required, or subsequent to such modification, the flow passes to block 440, 
wherein the flow returns to block 356 of FIG. 6. 

The architecture of the target apphcation interface is shown in the block 
diagram of FIG. 9. The target application interface 222 conmiunicates with the 
globalization manager engine 100, which accesses the application content 
database interface 2221. The application content database interface accesses 
("talks to") tiie target (customer's) apphcation content database 230, in which 
database the customer's web page content resides. In this manner, the GCM 
engine 100, through the application content database interface 2221 and using an 
appropriate driver, such as Java Database Connectivity (JDBC) or Open Database 
Connectivity (ODBC), pulls out the customer's web page content, checks it, and 
is able to make changes thereto. The apphcation content database interface 2221 
also provides an interface with an XML data source 232 for ti-ansfer of 
information to the GCM engine 100. The target apphcation interface 222 also 
includes the means to talk to any content management system, such as through 
the filters 214, 216 and 218, which respectively provide an interface between the 
VIGNETTE story server 1000, the Interwoven server 1200, and remote web site 
file system 1002 and web site local file system 1202. The data received through 
the filters 214, 216 and 218 is supplied to the GCM engine 100 through a content 
management system interface 212. 

Referring now to tiie flow chart representing the target application 



15 



interface customization process in FIG. 10, the flow passes from the starting 
point 450 to the decision block 452. Decision block 452 determines whether the 
data source is of the Vignette type. If it is, the flow passes to block 460 wherein 
any target application interface customization is provided, if needed. If it is not a 
Vignette data source, the flow passes to decision block 454 wherein it is 
determined whether the data source is an Interwoven type. If the data source is 
an Interwoven type, the flow passes to block 460. If it is not an Interwoven data 
source, the flow passes to block 456, wherein it is determined whether the data 
source is a database. If the data source is a database, the flow passes to block 
460, otherwise, the flow passes to decision block 458. Decision block 458 
determines whether the data source is a file. If the data source is a file, flow 
passes to block 460. If it is not a file type, the flow passes to block 462, since the 
data must be a new type of data source, the flow not having been previously 
diverted to block 460, and therefore requires the creation of a new target 
application interface for that data source. From block 460, and block 462, the 
flow passes to block 464, wherein the process is returned to block 360 of FIG. 6. 

In FIG. 1 1, the steps involved in the setup of the globalization manager are 
shown. From the starting point at block 466, the flow passes to block 468 
wherein the multiple customer web sites are all configured and the GM server. 
From block 468, the flow passes to block 470 wherein the target application 
interface is installed and the resource information is set up. From block 470, the 
flow passes to block 472. In block 472, the resource sharing and security 
parameters are set up. From block 472, the flow passes to block 474 wherein the 
electronic translation portal account is set up so that automated translation 
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processing can be accomplished. One such electronic translation portal is found a 
www.uniscape.com. From block 474, the flow passes to block 476, wherein the 
processing is returned to block 362 of FIG. 6. 

In FIG. 12, there is shown the flow chart associated with the global 
resource management process. The process contains three steps, user 
management in block 482, site relationship management in block 484, and project 
and work flow management in block 486. From block 486, the flow passes to 
block 488, wherein the process flow is returned to block 364 of FIG. 6. The 
processes involved in each of the three steps of blocks 482, 484 and 486 are 
further detailed in HG. 13, 15 and 16, respectively. 

The user management process is shown in FIG. 13. From the start block 
490, the flow passes to decision block 492 wherein it is determmed whether the 
process is for a new user, or not. If it is not a new user, the flow passes to block 
494 wherein the user logs in to the system and the user's identification is 
checked. From block 494, the flow passes to block 496 wherein it is determined 
whether the user's identification is vaHd. If it is not, flow passes back to block 
494. If the user's identification is valid, the flow then passes to block 518, 
wherein the process is returned to block 482 of FTG. 12. 

If in block 492 it is determined that the user is a new user, the flow passes 
to block 498 wherein a new user login identification is created. From block 498, 
the flow passes to decision block 500 wherein it is determined whether a new 
user role is needed. The user's role has to do with their responsibility associated 
with the user's system. For instance, the user's role may be management of a 
particular one of multiple web sites, or the particular user may be the 
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administrator for all of the user's web sites. Other roles include engineer, 
developer, translator, workflow administrator, system administrator, project 
manager, etc. If a new user role is not needed, i.e. a predefined role is to be used, 
the flow passes to block 502, wherein the role is assigned to the user and then the 
flow passes to block 494 for the user's login to the system. If, however, a new 
user role is needed, the flow passes from decision block 500 to block 504 wherein 
the new user role is created. In creating a new roles, the user gives the new role a 
name, such as "localization manager", and enters a detailed description of the 
role. From block 504, the flow passes to decision block 506 wherein it is 
determined whether new role responsibilities are needed. For some roles, 
responsibilities have been predetermined, however, where responsibilities of the 
user differ from those already identified, the other responsibilities can be 
assigned to a particular role. If no adjustment to the responsibilities is required, 
the flow passes to block 508 wherein the predetermined responsibilities are 
assigned to the role and flow then passes to block 502. Where new 
responsibilities are required, the flow passes to block 510 wherein the new role 
responsibilities are created. From block 510, the flow passes to decision block 
512 wherein it is determined whether new actions need to be associated with a 
particular responsibility. Actions are essentially privileges that the user may be 
granted for accessing the system, creating or updating a web site, creating or 
updating just one page of a web site, or any other action that would be associated 
with a particular user management role. Therefore, if no additional actions over 
those which have been predetermined for particular responsibility are required, 
the flow passes to block 516 wherein those predetermined actions are assigned to 
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the particular responsibility of the user and the flow then passes to block 508. If, 
however, new actions are requked, then the flow passes to block 514 wherein 
those actions are created for the particular responsibility and then flow passes to 
block 516. 

Before discussing the site-to-site relationship management process, it is 
believed that a review of a provider and subscriber model, like that shown in FIG. 
14, may be beneficial. FIG. 14 depicts a hypothetical model for a large 
Corporation having a number of web sites worldwide. The Corporation has two 
main corporate level web sites 40 and 50 which are identified as providers of 
resources to many of the other sites 42, 44, 45, 52 and 54. A site 52 which may 
represent a manufacturing operation of the Corporation is a subscriber to both of 
the main corporate level sites 40 and 50, wherein the sites 42, 44 and 45 are 
subscribers of the corporate level site 40 and the site 54 is a subscriber of the site 
50. The site 44 in addition to being a subscriber of resources from site 40 is also 
a provider to each of two other sites 46 and 48. The site of the manufacturing 
operation 52 is a provider to two other sites 56 and 58. Site 58 represents a 
Japanese operation of the Corporation, for example, and therefore some of the 
resources which are introduced into that site needs to be reflected in the U.S. and 
European sites, for example. Therefore, the Japanese site 58 is also a provider 
site for the sites 52 and 54. Once a model of the relationships between the sites is 
established, the process for specifymg the site-to-site relationships for the 
resource globalization process can be performed. 

Referring now to FIG. 15, there is shown a flow chart for the site-to-site 
relationship management process. From the starting point 520, the flow passes to 
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decision block 522 wherein it is determined whether the user who has logged on 
has a role which allows them to create new sites. If they have such access rights, 
then the flow passes to block 524 wherein they create the site with its locale 
information. Locale has four components; language, territory, character coding, 
and sorting scheme. The character coding may vary with the language in which 
the page is presented. In the U.S., characters are encoded utilizing an ASCII 
coding. In the U.S., the sorting is usually done utilizing a dictionary sort routine, 
wherein upper case characters have precedence over lower case. The user can 
specify the sorting scheme in the site creation step. From block 524, the flow 
passes to decision block 526. If in decision block 522, the user does not have 
authority to create a site, then the flow from decision block 522 passes also to 
decision block 526. In decision block 526, it is determined whether the user has 
authority to create a data source. If the user does not have such authority, the 
flow passes to block 530. If the user does have the authority, the flow passes to 
block 528 wherein the data source and its associated security information are 
created. In block 528, the flow passes to block 530. In block 530, the user 
specifies the necessary information for the target application interface so that it 
can properly communicate with the data source. As previously discussed, the 
target application interface allows a transfer of files and folders between the 
globalization manager and the site's data source. 

From block 530, the flow passes to decision block 534 wherein it is 
determined whether the site is to take on the role as a resource provider to other 
sites. If the site is to be a provider, then the flow passes to block 534. In block 
534, the globalization manager workflow daemon copies the data items from the 
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provider resource data source into the subscriber's staging area. From block 534, 
the flow passes to block 536. If the site is not a provider, then the flow passes 
from decision block 534 to decision block 536. Decision block 536 determines 
whether the site is a subscriber site. If it is not, the flow passes from block 536 to 
decision block 540. If the site is a subscriber site, then the flow passes to block 
538. In block 538, the content sources are identified. In accordance with the 
provider/subscriber model utilized when the site was set up, the particular site 
may be a subscriber to multiple providers, and those linkages are identified for 
further processing. From block 538, the flow passes to decision block 540. In 
decision block 540, it is determined whether the source content items need to be 
hidden. If they do, flow passes to block 542 wherein the source contents are 
marked (flagged) with a HIDE action. From block 542, the flow passes to 
decision block 544. If the source content items do not require hiding, then the 
flow passes directly from decision block 540 to decision block 544. In decision 
block 544, it is determined whether the source content data items can be directly 
copied to the target site without modification. If it can, then the flow passes to 
block 546 wherein the contents are marked with a COPY action. From block 
546, the flow passes to decision block 548. If in decision block 544, the data 
items could not be directiy copied, then the flow also passes to decision block 
548. In decision block 548, it is determined whether the data items need to be 
ti-anslated. If they do, the flow passes to block 550 wherein the data items are 
marked with a TRANSLATE action. From block 550, the flow passes to 
decision block 532, as does the flow from decision block 548 where the data 
items do not require translation. In block 552, it is determined whether the data 
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items need to be changed before they are copied. If they do, then the flow passes 
to block 554 wherein the data items are marked with a LOCALIZE action. From 
block 544, the flow passes to block 556. If the data items did not require 
modification prior to copying, then the flow from block 552 passes to block 556, 
wherein the process passes back to block 484 of FIG. 12. Note that Hide, Copy, 
Localize, and Translate are examples of business rules. Any other business rules, 
such as Search and Replace, can be incorporated into the process steps discussed 
in preceding paragraphs. 

In FIG. 16, the flow chart for the project management process is shown. 
From the start block 560, the flow passes to decision block 562 wherein it is 
determined whether or not a new project is being processed. If a new project is 
being processed, the flow passes from block 562 to block 564. In block 564, a 
new project name and description is created. Flow passes then from block 564 to 
block 566 wherein a recurring project schedule is set up. From block 566, the 
flow passes to block 568, wherein the project actions are set up. The process of 
setting up project actions will be further described in following paragraphs. From 
block 568, the flow passes to block 570 wherein a workflow template is 
identified with the project. The workflow template is an identification of the 
process steps needed for the project including identification of vendors for 
providing translation and review services. From block 570, the flow passes to 
block 572 wherein the workflow daemon is launched to automatically handle the 
workflow process. From block 572, the flow then passes to decision block 574. 
If in block 562, the project was not identified as a new project, then the flow from 
decision block 562 would also flow to decision block 574. 
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In decision block 574, it is determined whether the site-to-site 
relationships have been assigned to the particular project. If it has not, the flow 
passes to block 588. If the site-to-site relationships have been defined, then the 
flow passes to decision block 576. In decision block 576 it is determined whether 
the project daemon has detected that the current time coincides with a scheduled 
resource change detection time period of the project schedule. If it has not, this 
test is repeated until concurrence of the current time with the scheduled change 
detection schedule occurs. When concurrence is detected, the flow passes from 
block 576 to block 578. In block 578, the automatic detection of a resource 
change of the provider data source is performed and then flow passes to decision 
block 580. In block 580, it is determined whether there has been a change in the 
source content. If no change is detected, the flow then passes back to decision 
block 576 to repeat the sequence at the next scheduled time period. If, however, 
a change is detected, the flow passes from decision block 580 to block 582. In 
block 582, the project actions are executed to appropriately transfer the resource, 
either directly, translated, or localized, from the source to the subscriber. From 
block 582, the flow passes to decision block 584 wherein it is determined 
whether the project action has been completed. If it has not, then the flow passes 
to block 586 wherein the process is put on hold until the project actions have 
been completed. From block 586, the flow passes to block 588, as does the flow 
from decision block 584 if it is determined therein that the project action had 
finished. In block 588, the user is able to view the current or previous project 
status. From block 588, the flow passes to block 590, which transfers the flow 
back to block 486 of FIG. 12. 
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The process in setting up project actions is illustrated in FIG. 17. From 
the start block 592, the flow passes to decision block 594 wherein it is determined 
whether the source content data items are marked with a HIDE action. If they 
are, flow passes to block 596, which essentially transfers the flow to decision 
block 598 without taking any action. If the source content data items are not 
marked with a HIDE action, the flow also passes to decision block 598, wherein 
it is determined whether the source content data items are marked with a COPY 
action. If they are marked with a COPY action, then the flow passes to block 600 
wherein the source content is copied into the local staging area of the target site. 
From block 600, the flow then passes to decision block 602, as does the flow 
from block 598 if the source content data items are not marked with a COPY 
action. In decision block 602, it is determined whether the source content data 
items need to be translated prior to their deployment, transfer to the subscriber 
site. If translation is required, the flow passes to block 604 wherein the 
translation process is undertaken. Subsequent to completion of the translation 
process, the flow passes from block 604 to decision block 606. If translation was 
not required, then the flow from decision block 602 then passes to decision block 
606, as well. Decision block 606 determines whether the source content data 
items need to be changed (localized) and deployed. If change is required, the 
flow passes to block 608, wherein the source content data items are sent to local 
content editors who perform the localization necessary for the locale associated 
with the web site. If the source does not require modification, the flow passes 
from decision block 606 to block 610, as does the flow from block 608. In block 
610, the new contents is forwarded to local reviewers or marketers to insure the 
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content is proper for the locale. From block 610, the flow passes to decision 
block 612 wherein it is determined whether the local reviewers or marketers have 
approved the new contents. If they have not approved those contents, flow 
passes to block 614, wherein the contents are further modified in accordance with 
the requirements of the reviewers or marketers and then the flow passes back to 
block 610. If it is determined that the new contents have been approved, then the 
flow passes from block 612 to block 616. In block 616, the new content is 
labeled as such. From block 616, the flow passes to block 618. In block 618, the 
appropriate target application interface is initiated to insert the new content into 
the target space. From block 618, the flow passes to block 620 wherein the 
process passes back to block 568 of FIG. 16. 

Turning now to FIG. 18, there is shown a flow chart for the global 
resource translation process. From the starting point of block 622, the flow 
passes to block 624, In block 624, the project daemon automatically creates the. 
ordering information and submits such to the electronic translation portal. From 
block 624, the flow passes to decision block 626, wherein it is determined 
whether the order had been submitted. If the order was not submitted, the flow 
passes to block 628, wherein order submission error handhng procedures are 
carried out. From block 628, the flow passes back to block 624. If it is 
determined in decision block 626 that the order has been submitted, then the flow 
passes to block 630 wherein the files to be translated are copied and uploaded to 
the electronic translation portal. From block 630, the flow passes to decision 
block 632, wherein it is determined whether the files have been uploaded. If the 
uploading has not occurred, the flow passes to block 634, wherein the file 
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uploading error handling procedures are carried out. From block 634, the flow 
passes back to block 630. If die files have been successfully uploaded, then the 
flow passes from decision block 632 to block 636. In block 626, the process is 
put on hold until the electronic translation portal indicates that the translations 
have been completed. From block 636, the flow passes to block 638 wherein the 
translated files are downloaded from the electronic translation portal into a local 
staging area. From block 638, the flow passes to the decision block 640. 
Decision block 640 determines whether the files have been successfully 
downloaded. If they have not, the flow passes to block 642 wherein error 
handling procedures for downloading files is carried out. From block 642, the 
flow passes back to block 638. If decision block 640 determines that the files 
have been successfully downloaded, the flow then passes to block 644 wherein 
the process is returned to block 604 of FIG. 17. 

Although this invention has been described in connection with specific 
forms and embodiments thereof, it will be appreciated that various modifications 
other than those discussed above may be resorted to without departing from the 
spirit or scope of the invention. For example, equivalent elements may be 
substituted for those specifically shown and described, certain features may be 
used independently of other features, and in certain cases, particular locations of 
elements may be reversed or interposed, all without departing from the spirit or 
scope of the invention as defined in the appended Claims. 



